前言：這段程式碼「看起來」沒問題，就代表真的沒問題嗎？

「這個 PR 的程式碼邏輯清楚、測試也補齊了，AI 說可以合併，那應該沒問題吧？」

PHPUnit & Pest Test Explorer 這個專案採用的是 MIT License——一個對商業使用、修改、再散布都很寬鬆的授權條款（用 gh repo view recca0120/vscode-phpunit --json licenseInfo 查證過，結果確實是 MIT License）。但「這個專案本身用什麼授權」跟「外部貢獻者提交的每一段程式碼,有沒有資格被收進這個授權底下」，是兩個完全不同層次的問題——而後者，正是今天要講的、AI 不該自己拍板的責任。

今日目標

• 理解「程式碼邏輯正確」跟「程式碼有沒有授權瑕疵」是兩條獨立的審查軸線
• 認識外部貢獻常見的授權疑慮長什麼樣（不是危言聳聽，是具體情境）
• 看清楚為什麼這類判斷不能交給 AI 自己決定
• 建立一套「AI 該做什麼、人一定要接手什麼」的分工原則

一段程式碼「寫得好」，不代表它「可以被收下」

外部貢獻者提交 PR 時，AI review（或任何 code review）通常聚焦在：這段程式碼有沒有 bug、有沒有測試、風格符不符合專案慣例、會不會破壞既有行為。這些都是技術層面的判斷，AI 做得不錯。

但還有一類問題，AI 的判斷基礎完全不夠：這段程式碼是不是原創的？ 一位貢獻者可能是從另一個授權條款更嚴格的專案（例如 GPL）複製了一段程式碼過來，改個變數名稱就提交上來——邏輯正確、風格也調整過、測試也補了，表面上完全看不出破綻。AI 讀程式碼的方式是理解「這段邏輯在做什麼」，不是比對「這段邏輯的表達方式，是不是似曾相識於某個授權不相容的來源」。這件事需要的是人的警覺跟經驗，不是語法或邏輯層面的分析。

為什麼這類判斷必須留給人

授權判斷本質上不是「這段程式碼對不對」的問題，而是「這個專案的維護者，願不願意為這段程式碼的來源背書」的問題。 一旦一段有授權瑕疵的程式碼被合併進一個 MIT 授權的專案，後續所有下游使用者（包括企業使用者）都在無意間承接了這個風險——而承擔這個責任的，是掛名維護者，不是幫忙審查的 AI。

用一組對照來看這個差異：

❌ 讓 AI 自己拍板：
「這段程式碼邏輯正確、測試也過了，可以合併。」
→ AI 只驗證了「這段程式碼能不能動」，
  沒有、也沒有能力驗證「這段程式碼的來源乾不乾淨」

✅ AI 提供資訊，人做最終判斷：
「這段程式碼邏輯正確、測試也過了。
 但這是外部貢獻者的第一次提交，且改動的是一個
 相對少見的演算法實作——建議維護者親自確認一下
 這段實作是不是原創，再決定要不要合併。」
→ AI 標注出「這是需要人特別留意的情境」，
  但不假裝自己有資格替維護者背書

AI 可以幫忙標注「這裡有需要人特別注意的訊號」，但不能替維護者做出「我願意為這段程式碼的來源負責」這個判斷本身。 這跟系列前面幾天講過的「AI 只能呈現選項，決定權在人」是同一個邏輯——只是這裡的決定權，牽涉的不只是技術取捨，還有法律跟倫理層面的責任歸屬。

這條界線也適用在「看起來只是小事」的地方

授權疑慮不是只會出現在「整段演算法複製貼上」這種明顯情境。一段從 Stack Overflow 複製來的程式碼片段、一份直接引用自另一個開源專案文件的說明文字、甚至是一張隨手從網路上找來的圖示素材——這些「看起來只是順手引用」的小東西，同樣可能牽涉授權相容性。AI 在處理這類貢獻時，容易因為「內容本身沒有邏輯錯誤」就直接判定沒問題，卻沒有意識到「這段內容從哪裡來」才是真正該被審視的問題。

今日思考題

回想你維護（或參與）過的專案：如果今天有一個外部貢獻者提交的 PR，程式碼寫得很好、測試也齊全，但你完全不知道這段實作的靈感或原始碼是從哪裡來的，你會怎麼處理？你有沒有一套明確的判斷標準，還是純粹憑當下的直覺？

今日重點回顧

• 「程式碼邏輯正確」跟「程式碼來源乾淨、授權相容」是兩條獨立的審查軸線，AI 只擅長前者
• 授權疑慮不限於整段程式碼複製貼上，文件、素材這類「順手引用」的內容一樣可能有問題
• AI 能標注「這裡有需要人特別留意的訊號」，但沒有資格替維護者背書「這段來源沒問題」
• 這類判斷牽涉法律與倫理層面的責任歸屬，責任在掛名維護者身上，不是協助審查的 AI

明日預告

明天要換一個更貼近日常維運的主題：Release 流程——AI 能把版本發布這件事自動化到什麼程度，又有哪些檢查一定要留給人親自核准才能按下發布鍵。